Auto merge of #2946 - alexcrichton:build-script-metadata, r=brson

Always pass `-C metadata` to the compiler

If it's not otherwise available we just key it off the pkgid which should be
unique enough across compilations. This should help incremental compilation
efforts be "more incremental" across projects.

Closes #2943

Always pass `-C metadata` to the compiler

If it's not otherwise available we just key it off the pkgid which should be
unique enough across compilations. This should help incremental compilation
efforts be "more incremental" across projects.

Closes #2943

Auto merge of #2857 - alexcrichton:redirect-sources, r=brson

Add support local mirrors of registries, take 2

This series of commits culminates in first class support in Cargo for local mirrors of registries. This is implemented through a number of other more generic mechanisms, and extra support was added along the way. The highlights of this PR, however, are:

New `.cargo/config` keys have been added to enable *replacing one source with another*. This functionality is intended to be used for mirrors of the main registry or otherwise one to one source correspondences. The support looks like:

```toml
[source.crates-io]
replace-with = 'my-awesome-registry'

[source.my-awesome-registry]
registry = 'https://github.com/my-awesome/registry-index'
```

This configuration means that instead of using `crates-io` (e.g. `https://github.com/rust-lang/crates.io-index`), Cargo will query the `my-awesome-registry` source instead (configured to a different index here). This alternate source **must be the exact same as the crates.io index**. Cargo assumes that replacement sources are exact 1:1 mirrors in this respect, and the following support is designed around that assumption.

When generating a lock file for crate using a replacement registry, the *original registry* will be encoded into the lock file. For example in the configuration above, all lock files will still mention crates.io as the registry that packages originated from. This semantically represents how crates.io is the source of truth for all crates, and this is upheld because all replacements have a 1:1 correspondance.

Overall, this means that no matter what replacement source you're working with, you can ship your lock file to anyone else and you'll all still have verifiably reproducible builds!

With the above support for custom registries, it's now possible for a project to be downloading crates from any number of sources. One of Cargo's core goals is reproducible builds, and with all these new sources of information it may be easy for a few situations to arise:

1. A local replacement of crates.io could be corrupt
2. A local replacement of crates.io could have made subtle changes to crates

In both of these cases, Cargo would today simply give non-reproducible builds. To help assuage these concerns, Cargo will now track the sha256 checksum of all crates from registries in the lock file. Whenever a `Cargo.lock` is generated from now on it will contain a `[metadata]` section which lists the sha256 checksum of all crates in the lock file (or `<none>` if the sha256 checksum isn't known).

Cargo already checks registry checksums against what's actually downloaded, and Cargo will now verify between iterations of the lock file that checksums remain the same as well. This means that if a local replacement registry is **not** in a 1:1 correspondance with crates.io, the lock file will prevent the build from progressing until the discrepancy is resolved.

In addition to the support above, there is now a new kind of source in Cargo, a "local registry", which is intended to be a subset of the crates.io ecosystem purposed for a local build for any particular project here or there. The way to enable this looks like:

```toml
[source.crates-io]
replace-with = 'my-awesome-registry'

[source.my-awesome-registry]
local-registry = 'path/to/my/local/registry'
```

This local registry is expected to have two components:

1. A directory called `index` which matches the same structure as the crates.io index. The `config.json` file is not required here.
2. Inside the registry directory are any number of `.crate` files (downloaded from crates.io). Each crate file has the name `<package>-<version>.crate`.

This local registry must currently be managed manually, but I plan on publishing and maintaining a Cargo subcommand to manage a local registry. It will have options to do things like:

1. Sync a local registry with a `Cargo.lock`
2. Add a registry package to a local registry
3. Remove a package from a local registry

In addition to local registries, Cargo also supports a "directory source" like so

```toml
[source.crates-io]
replace-with = 'my-awesome-registry'

[source.my-awesome-registry]
directory = 'path/to/some/sources'
```

A directory source is similar to a local registry above, except that all the crates are unpacked and visible as vendored source. This format is suitable for checking into source trees, like Gecko's.

Unlike local registries above we don't have a tarball to verify the crates.io checksum with, but each vendored dependency has metadata containing what it *would* have been. To further prevent modifications by accident, the metadata contains the checksum of each file which should prevent accidental local modifications and steer towards `[replace]` as the mechanism to edit dependencies if necessary.

This is quite a bit of new features! What's all this meant to do? Some example scenarios that this is envisioned to solve are:

1. Supporting mirrors for crates.io in a first class fashion. Once we have the ability to spin up your own local registry, it should be easy to locally select a new mirror.
2. Supporting round-robin mirrors, this provides an easy vector for configuration of "instead of crates.io hit the first source in this list that works"
3. Build environments where network access is not an option. Preparing a local registry ahead-of-time (from a known good lock file) will be a vector to ensure that all Rust dependencies are locally available.
   * Note this is intended to include use cases like Debian and Gecko

Even with the new goodies here, there's some more vectors through which this can be expanded:

* Support for running your own mirror of crates.io needs to be implemented to be "easy to do". There should for example be a `cargo install foo` available to have everything "Just Work".
* Replacing a source with a list of sources (attempted in round robin fashion) needs to be implemented
* Eventually this support will be extended to the `Cargo.toml` file itself. For example:
  * packages should be downloadable from multiple registries
  * replacement sources should be encodable into `Cargo.toml` (note that these replacements, unlike the ones above, would be encoded into `Cargo.lock`)
  * adding multiple mirrors to a `Cargo.toml` should be supported
* Implementing the subcommand above to manage local registries needs to happen (I will attend to this shortly)

Auto merge of #2945 - QuiltOS:openssl, r=alexcrichton

Use openssl on Unix rather than C functions directly for SHA256

Takes on an extra dependency, but removes unsafe code in the process.

@alexcrichton I was a little confused by what you were saying on IRC, so I went ahead and just speculatively made this. No worries if it is no good.

Use openssl on Unix rather than C functions directly for SHA256

Add documentation for source replacement

Auto merge of #2942 - jseyfried:remove_unused_import, r=alexcrichton

Remove unused import

c.f. https://github.com/rust-lang/rust/pull/35116

Remove unused import

Addressing review comments

Implement a directory source

This flavor of source is intended to behave like a local registry except that
its contents are unpacked rather than zipped up in `.crate` form. Like with
local registries the only way to use this currently is via the
`.cargo/config`-based source replacement currently, and primarily only to
replace crates.io or other registries at the moment.

A directory source is simply a directory which has many `.crate` files unpacked
inside of it. The directory is not recursively traversed for changes, but rather
it is just required that all elements in the directory are themselves
directories of packages.

This format is more suitable for checking into source trees, and it still
provides guarantees around preventing modification of the original source from
the upstream copy. Each directory in the directory source is required to have a
`.cargo-checksum.json` file indicating the checksum it *would* have had if the
crate had come from the original source as well as all of the sha256 checksums
of all the files in the repo. It is intended that directory sources are
assembled from a separately shipped subcommand (e.g.  `cargo vendor` or `cargo
local-registry`), so these checksum files don't have to be managed manually.

Modification of a directory source is not the intended purpose, and if a
modification is detected then the user is nudged towards solutions like
`[replace]` which are intended for overriding other sources and processing local
modifications.

Implement a local registry type

This flavor of registry is intended to behave very similarly to the standard
remote registry, except everything is contained locally on the filesystem
instead. There are a few components to this new flavor of registry:

1. The registry itself is rooted at a particular directory, owning all structure
   beneath it.
2. There is an `index` folder with the same structure as the crates.io index
   describing the local registry (e.g. contents, versions, checksums, etc).
3. Inside the root will also be a list of `.crate` files which correspond to
   those described in the index. All crates must be of the form
   `name-version.crate` and be the same `.crate` files from crates.io itself.

This support can currently be used via the previous implementation of source
overrides with the new type:

```toml
[source.crates-io]
replace-with = 'my-awesome-registry'

[source.my-awesome-registry]
local-registry = 'path/to/registry'
```

I will soon follow up with a tool which can be used to manage these local
registries externally.

Refactor the RegistrySource implementation

Add an abstraction over which the index can be updated and downloads can be
made. This is currently implemented for "remote" registries (e.g. crates.io),
but soon there will be one for "local" registries as well.

Add sha256 checksums to the lockfile

This commit changes how lock files are encoded by checksums for each package in
the lockfile to the `[metadata]` section. The previous commit implemented the
ability to redirect sources, but the core assumption there was that a package
coming from two different locations was always the same. An inevitable case,
however, is that a source gets corrupted or, worse, ships a modified version of
a crate to introduce instability between two "mirrors".

The purpose of adding checksums will be to resolve this discrepancy. Each crate
coming from crates.io will now record its sha256 checksum in the lock file. When
a lock file already exists, the new checksum for a crate will be checked against
it, and if they differ compilation will be aborted. Currently only registry
crates will have sha256 checksums listed, all other sources do not have
checksums at this time.

The astute may notice that if the lock file format is changing, then a lock file
generated by a newer Cargo might be mangled by an older Cargo. In anticipation
of this, however, all Cargo versions published support a `[metadata]` section of
the lock file which is transparently carried forward if encountered. This means
that older Cargos compiling with a newer lock file will not verify checksums in
the lock file, but they will carry forward the checksum information and prevent
it from being removed.

There are, however, a few situations where problems may still arise:

1. If an older Cargo takes a newer lockfile (with checksums) and updates it with
   a modified `Cargo.toml` (e.g. a package was added, removed, or updated), then
   the `[metadata]` section will not be updated appropriately. This modification
   would require a newer Cargo to come in and update the checksums for such a
   modification.

2. Today Cargo can only calculate checksums for registry sources, but we may
   eventually want to support other sources like git (or just straight-up path
   sources). If future Cargo implements support for this sort of checksum, then
   it's the same problem as above where older Cargos will not know how to keep
   the checksum in sync

Implement source redirection

This commit implements a scheme for .cargo/config files where sources can be
redirected to other sources. The purpose of this will be to override crates.io
for a few use cases:

  * Replace it with a mirror site that is sync'd to crates.io
  * Replace it with a "directory source" or some other local source

This major feature of this redirection, however, is that none of it is encoded
into the lock file. If one source is redirected to another then it is assumed
that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in
both location). The lock file simply encodes the canonical soure (e.g.
crates.io) rather than the replacement source. In the end this means that
Cargo.lock files can be generated from any replacement source and shipped to
other locations without the lockfile oscillating about where packages came from.

Eventually this support will be extended to `Cargo.toml` itself (which will be
encoded into the lock file), but that support is not implemented today. The
syntax for what was implemented today looks like:

    # .cargo/config
    [source.my-awesome-registry]
    registry = 'https://example.com/path/to/index'

    [source.crates-io]
    replace-with = 'my-awesome-registry'

Each source will have a canonical name and will be configured with the various
keys underneath it (today just 'registry' and 'directory' will be accepted). The
global `crates-io` source represents crates from the standard registry, and this
can be replaced with other mirror sources.

All tests have been modified to use this new infrastructure instead of the old
`registry.index` configuration. This configuration is now also deprecated and
will emit an unconditional warning about how it will no longer be used in the
future.

Finally, all subcommands now use this "source map" except for `cargo publish`,
which will always publish to the default registry (in this case crates.io).

Improve Debug for PackageId

Add convenience helpers to map source ids

Should help easily mapping packages from one source to another

Get Box<Source> to implement Source

Remove some dead code

Refactor URL parsing, be more robust for decoding errors

URL parsing now returns a `CargoResult` and also change a few `unwrap()` calls
to returning a `CargoResult` when decoding various bits and pieces of
information.

Auto merge of #2940 - matklad:ambiguous-deps, r=alexcrichton

Warn about unused keys in dependency specification

Closes #2869 and #2695

Warn about unused keys in dependency specification

Auto merge of #2938 - alexcrichton:virtual-in-git, r=brson

Fix depending on git repos with workspaces

When we're recursively walking over a git repository we can safely ignore any
workspace Cargo.toml files we find instead of generating an error.

Fix depending on git repos with workspaces

When we're recursively walking over a git repository we can safely ignore any
workspace Cargo.toml files we find instead of generating an error.

Auto merge of #2933 - steveklabnik:semver_testing, r=alexcrichton

bump to newer semver version

I've just released semver `0.4.0`. Locally, the tests mostly passed, but not some of the cross-compilation tests. So I'm opening this PR to see what CI says.

Auto merge of #2934 - jethrogb:patch-2, r=alexcrichton

Clarify [replace] section capabilities

Clarify [replace] section capabilities

regenerate the lockfile

bump to newer semver version

Auto merge of #2921 - jonathandturner:bin_by_default, r=alexcrichton

Add --lib and status message for completion

This PR adds a --lib flag for creating a library with new/init.  It also adds a status message for a successful completion.

Add tests for passing both --bin and --lib

Add --lib to init/new. Add status message for completed creation

Auto merge of #2927 - alexcrichton:fix-nightiles, r=alexcrichton

Add a sleep to a rebuilding test to fix nightlies

Just the standard issue with fs timestamps, OSX, etc.

Add a sleep to a rebuilding test to fix nightlies

Just the standard issue with fs timestamps, OSX, etc.

Auto merge of #2924 - luser:error-removing-file, r=alexcrichton

Print a more useful error message when the target binary can't be removed

This happens sometimes on Windows if the target is still running, and right
now cargo prints a very cryptic message:
```
$ cargo build
   Compiling sccache v0.1.0 (file:///C:/build/sccache2)
An unknown error occurred
```

With this patch we get a much more useful error:
```
$ ../cargo/target/debug/cargo build
   Compiling sccache v0.1.0 (file:///C:/build/sccache2)
error: Could not remove file: c:\build\sccache2\target\debug\sccache.exe.

To learn more, run the command again with --verbose.
```

Print a more useful error message when the target binary can't be removed.

This happens sometimes on Windows if the target is still running, and right
now cargo prints a very cryptic message:
```
$ cargo build
   Compiling sccache v0.1.0 (file:///C:/build/sccache2)
An unknown error occurred
```

With this patch we get a much more useful error:
```
$ ../cargo/target/debug/cargo build
   Compiling sccache v0.1.0 (file:///C:/build/sccache2)
error: Could not remove file: c:\build\sccache2\target\debug\sccache.exe.

To learn more, run the command again with --verbose.
```

Auto merge of #2919 - alexcrichton:workspace-rebuild, r=brson

Always build libraries into the same location

Previously Cargo would compile a library into a different location depending on
whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's
reliance on the idea of a "root crate" this PR is the next step. With workspaces
the root crate of a compliation changes all the time, so the output needs to be
the same whether a crate is at the root or not.

Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise
due to this discrepancy. Additionally, Cargo will no longer recompile a library
when it's used as a "root crate" or not.

This is fixed by taking a few steps:

* Everything is now compiled into the `deps` directory, regardless of whether
  it's a root output or not.
* If a "root crate" is being compiled, then the relevant outputs are hard-linked
  up one level to where they are today. This means that your binaries, dylibs,
  staticlibs, etc, will all show up where they used to.
* The `-C metadata` flag is always omitted for path dependencies now. These
  dependencies are always path dependencies and already all have unique crate
  names. Additionally, they're the only crates in the DAG without metadata, so
  there's no need to provide additional metadata. This in turn means that none
  of the file names of the generated crates are mangled.

Closes #2855

Always build libraries into the same location

Previously Cargo would compile a library into a different location depending on
whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's
reliance on the idea of a "root crate" this PR is the next step. With workspaces
the root crate of a compliation changes all the time, so the output needs to be
the same whether a crate is at the root or not.

Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise
due to this discrepancy. Additionally, Cargo will no longer recompile a library
when it's used as a "root crate" or not.

This is fixed by taking a few steps:

* Everything is now compiled into the `deps` directory, regardless of whether
  it's a root output or not.
* If a "root crate" is being compiled, then the relevant outputs are hard-linked
  up one level to where they are today. This means that your binaries, dylibs,
  staticlibs, etc, will all show up where they used to.
* The `-C metadata` flag is always omitted for path dependencies now. These
  dependencies are always path dependencies and already all have unique crate
  names. Additionally, they're the only crates in the DAG without metadata, so
  there's no need to provide additional metadata. This in turn means that none
  of the file names of the generated crates are mangled.

Closes #2855

Auto merge of #2920 - alexcrichton:wut, r=brson

Improve file open error when packaging crates

Be sure to point to the file in question.

Closes #2914

Improve file open error when packaging crates

Be sure to point to the file in question.

Closes #2914

Auto merge of #2918 - munyari:man-pages, r=alexcrichton

Add man pages for cargo subcommands

From #2789

- [x] fetch
- [x] login
- [x] metadata
- [x] pkgid
- [x] rustc
- [x] rustdoc
- [x] uninstall
- [x] version
- [x] yank
- [x] generate_lockfile

Add man page for pkgid subcommand

add man page for rustdoc subcommand

add man page for uninstall subcommand

add man page for generate-lockfile subcommand

add man page for version subcommand

add man page for metadata subcommand

Add man page for cargo login

Auto merge of #2917 - alexcrichton:cainfo, r=brson

Add `http.cainfo` config for custom certs

This adds a `http.cainfo` option to Cargo which reads CA information from a
bundle to pass through to the underlying SSL implementation. This should allow
configuration of Cargo in situations where the default certificate store doesn't
contain the relevant certificates, such as behind corporate proxies.

cc #1180

Auto merge of #2909 - jonathandturner:debug_release_at_bottom, r=alexcrichton

Switch to output release/debug after compile

This is similar to https://github.com/rust-lang/cargo/pull/2896 but instead of inline, it puts an indicator at the bottom showing if it was a release or debug build.

```
jturner-23759:cargo jturner$ ./target/release/cargo build
Finished debug (unoptimized + debuginfo) build.
jturner-23759:cargo jturner$ ./target/release/cargo build --release
Finished release (optimized) build.
```

Add 'Finished' line after compile finishes with compile timing and build type

Add rustc man page

Add man page for cargo yank

Auto merge of #2915 - matklad:rename-shell, r=alexcrichton

Minor, rename function parameter

Naming `Config` as `shell` (while having a `shell` function in scope which returns `MultiShell`) inside this not so trivial callback driven fragment of code is devilishly evil :)

Add cargo fetch man page

Auto merge of #2910 - BusyJay:master, r=alexcrichton

Fix python detection

Some platform, like ArchLinux, may not have python in the PATH, but can still have python2. So we should add some fallback option to detect python correctly. This detection order is copy from [rust-lang/rust](https://github.com/rust-lang/rust/blob/master/configure#L742).

Add `http.cainfo` config for custom certs

This adds a `http.cainfo` option to Cargo which reads CA information from a
bundle to pass through to the underlying SSL implementation. This should allow
configuration of Cargo in situations where the default certificate store doesn't
contain the relevant certificates, such as behind corporate proxies.

cc #1180

Auto merge of #2913 - cuviper:disable-option-checking, r=alexcrichton

configure: Support --disable-option-checking

This is mirroring rust-lang/rust#31169.  The RPM %configure macro sets a
lot of useful paths for typical configure scripts, but some of these
values are not recognized here in Cargo.  It's nice to have an option to
ignore those, rather than failing on `validate_opt`.

Minor, rename function parameter

Auto merge of #2912 - matklad:move-target-dir, r=alexcrichton

Move `target_dir` to Workspace and fix #2848

Target dir is now an API of Workspace. It is still initialized eagerly, just later.

I also had to errors in the config file when retrieving `verbose` and `color` config. Seems fishy, but is probably OK.

configure: Support --disable-option-checking

This is mirroring rust-lang/rust#31169.  The RPM %configure macro sets a
lot of useful paths for typical configure scripts, but some of these
values are not recognized here in Cargo.  It's nice to have an option to
ignore those, rather than failing on `validate_opt`.

Fix config loading test

Ignore some config errors during init

While it is generally terrible to silently ignore errors in the
configuration files, it is acceptable in this case. Verbosity and color
config have reasonable defaults, and we don't want to fail for simple
commands like `cargo --version` just because of the garbage in the
config file.

fixed #2848

Read target config later

Fix python detection

Move `target_dir` to workspace

Auto merge of #2908 - froydnj:spelling-fixes, r=alexcrichton

fix typos in src/doc/manifest.md

A few things I noticed while reading the documentation.  The "sections" change is not strictly a spelling error, but I figured I would fix it while I was in the area.

fix typos in src/doc/manifest.md

Auto merge of #2907 - alexcrichton:alias-no-override, r=brson

Don't allow aliases to override builtin commands

Closes #2901

Don't allow aliases to override builtin commands

Closes #2901

Auto merge of #2900 - matklad:lazy-config, r=alexcrichton

Lazy config

Next piece of #2848.

* `config.rustc`  and `config.rustdoc` are now lazy.
* `Rustc` and not `config.rustc` now knows the path to the compiler.
* `LazyCell` is used to implement laziness

No new tests are added, because we need to lazify `target_path` to deal with broken cargo config.

`target_path` is a bit peculiar. It is always accessed as `ws.config.target_path(ws)`, and has a setter. Perhaps it belongs to the workspace? Will look into that later.

Use LazyCell to implement lazy Config

Coalesce config.rustc and config.rustc_info

Move path to rustc into Rustc struct

Scrape tools config lazily

Auto merge of #2811 - alexcrichton:network-is-error, r=brson

Add a flag to force network access to be an error

If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.

The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.

This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.

These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:

* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
  date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
  the network indicates a programmer error that something wasn't vendored
  correctly.

A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.

Closes #2111

Auto merge of #2893 - KasMA1990:patch-1, r=alexcrichton

Include reference to Rust code structuring

Hey guys, I'm proposing this little addition to the manifest. When I first started with Rust, I wanted to make a simple crate, so the "Getting Started" (and from there, the manifest) document on crates.io was a natural entry point for me. However, it would have helped getting over some headaches initially if the Cargo documentation had driven me into the relevant Rust documentation; in the beginning at least it wasn't clear to me where Cargo ended and Rust began, especially with modules.

I'm not sure if this should be in the actual manifest or in the "Getting Stated" doc, or if you want it there at all, but it's a quality-of-life thing that I think past-me would have appreciated at least :)

Include reference to Rust code structuring

Add flags to assert lock/cache behavior to Cargo

If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.

The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.

This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.

These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:

* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
  date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
  the network indicates a programmer error that something wasn't vendored
  correctly.

A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.

Closes #2111

Auto merge of #2891 - upsuper:fix-search-path, r=alexcrichton

Search dylib path from cargo before system

Cargo should have more knowledge about what it is looking for, and thus its paths should be more correct compared to system's. When there are conflicts, the search paths provided by the build system should take priority.

Search dylib path from cargo before system

Cargo should have more knowledge about what it is looking for, and thus
its paths should be more correct compared to system's. When there are
conflicts, the search paths provided by the build system should take
priority.

Auto merge of #2849 - wezm:publish_dry_run, r=alexcrichton

Add --dry-run to cargo publish

This PR picks up where @JustAPerson left off in https://github.com/rust-lang/cargo/pull/1699. I've updated their changes to apply to current master and added tests, including (I think) a test that checks that the upload doesn't actually occur.

The output is as it was before:


Closes https://github.com/rust-lang/cargo/issues/1332

Auto merge of #2889 - bennofs:fix-cargo-rustc-help, r=alexcrichton

fix help for cargo rustc -p

cargo rustc -p does the same as cargo build -p, so I just copied it from there.

Add --dry-run option to publish sub-command

Squashed commit of the following:

commit deed1d7b99c1cd142f7782d3b3b782d949e1f71f
Author: Wesley Moore <wes@wezm.net>
Date:   Fri Jul 15 13:35:01 2016 +1000

    Remove --dry-run and --no-verify mutual exclusion

commit 8a91fcf2a1aa3ba682fee67bb5b3e7c2c2cce8ef
Merge: 0c0d057 970535d
Author: Wesley Moore <wes@wezm.net>
Date:   Fri Jul 15 13:30:38 2016 +1000

    Merge remote-tracking branch 'upstream/master' into publish_dry_run

commit 0c0d0572533599b3c0e42797a6014edf480f1dc2
Author: Wesley Moore <wes@wezm.net>
Date:   Tue Jul 12 08:03:15 2016 +1000

    Improve grammar in --dry-run option

commit a17c1bf6f41f016cafdcb8cfc58ccbe34d54fbb8
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 14:17:41 2016 +1000

    Add test for passing no-verify and dry-run to publish

commit 284810cca5df3268596f18700c0247de2f621c98
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 14:51:38 2016 +1000

    Add test for publish --dry-run

commit 8514e47fbce61c20b227815887a377c25d17d004
Merge: 2b061c5 ef07b81
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 08:27:10 2016 +1000

    Merge branch 'publish_dry_run' of github.com:JustAPerson/cargo into publish_dry_run

commit ef07b81617df855328c34365b28049cd9742946c
Author: Jason Priest <jpriest128@gmail.com>
Date:   Tue Jun 9 23:11:51 2015 -0500

    Improve publish `--dry-run`

    Catch a few more errors by aborting midway through transmit().

commit 0686fb0bf92a09bcbd41e15e23ff03a0763c5d08
Author: Jason Priest <jpriest128@gmail.com>
Date:   Tue Jun 9 14:38:58 2015 -0500

    Teach publish the `--dry-run` flag

    Closes #1332

fix help for cargo rustc -p

Auto merge of #2887 - wuranbo:doc-explain-doublebrackets, r=alexcrichton

doc: manifest.md add explain about double-bracket

Add TOML doc ref to explain double-bracket sections like [[bin]].
It really confused me when I saw the double-bracket first. I search google, take some time, and then saw the TOML doc, recall that we can have more than one executable in Cargo, understood it. So it can be added to help someone like me (:

doc: manifest.md add explain about double-bracket

Auto merge of #2885 - nelhage:ssh-retry-loop, r=alexcrichton

git: only attempt ssh-agent authentication once

This prevents infinite looping if ssh-agent authentication fails.

closes #2845

git: only attempt ssh-agent authentication once

This prevents infinite looping if ssh-agent authentication fails.

closes #2845

Auto merge of #2883 - wuranbo:patch-1, r=alexcrichton

doc: typo

doc: typo

Auto merge of #2881 - matklad:lazy-rustc-info, r=alexcrichton

Lazy rustc info

This is the first step towards https://github.com/rust-lang/cargo/issues/2848.

Remove now unnecessary Rustc::blank method

Retrieve Rustc info lazily

Auto merge of #2879 - QuiltOS:replace-bug, r=alexcrichton

Fix #2595 by skipping reflexive replacements

If you know of something better than `source_id == source_id`, I'd gladly change it.

Merge branch 'master' into replace-bug

Fix #2595 by skipping reflexive replacements

Refactor replacement logic

Add minimal version of #2595 to test suite (test currently fails)

Auto merge of #2876 - bennofs:fix-2851, r=alexcrichton

allow enabling features for deps with --features

Fixes #2851

allow enabling features for deps with --features

Fixes #2851